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DETAILED ACTION 

1 . Claims 1-30 are presented for examination. 

Response to Arguments 

2. Applicant's arguments filed 9/13/2004 have been fully considered but they are not 
persuasive. Therefore, rejection of claims 1-30 is maintained. 

Applicant argues, (1) "In making this amendment, Applicant has not and does not in any 
way narrow the scope of protection to which Applicant considers the invention herein to be 
entitled and does not concede, in any way, that the subject matter of such Claims was in fact 
taught or disclosed by the cited prior art". The examiner disagrees in response to applicant's 
arguments. Claims 1 and 16 are amended, dated 9/13/2004, containing additional limitations, 
"all request packets from clients destined for the load balancing array", etc. Original claims, 1 
and 16, did not contain additional limitations, for example, multiple clients, multiple request 
packets etc. The limitations, "all request packets from clients destined for the load balancing 
array", etc, has been newly added, which is addressed by the new ground(s) of rejection (please 
refer to the below rejections of this office action), necessitated by the applicant's amendment. 
Therefore, the rejection is maintained. 

Applicant argues, (2) "Zisapel-Radware et al., US Publication, 2002/0103846 Al, "Load 
Balancing", Aug. 1, 2002, Radware Limited (Hereinafter Zisapel-Radware) does not teach or 
disclose a system wherein all request packets from clients destined for the load balancing array 
are routed through a scheduler as claimed in Claims 1 and 16. Anticipation under 35 U.S.C. 102 
requires a reference to teach or disclose each and every element, limitation, or step of a claim. 
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Since Claim 1 and Claim 16 each include at least one element not found in Zi sap el-Rad ware, the 
Zisapel-Radware patent does not anticipate Claim 1 or Claim 16 under 35 U.S.C. 102. Zisapel- 
Radware therefore does not teach every aspect of the claimed invention either explicitly or 
impliedly". The examiner disagrees in response to applicant's arguments. The limitations, "all 
request packets from clients destined for the load balancing array are routed through a 
scheduler", etc, has been newly added, which is addressed by the new ground(s) of rejection 
(please refer to the below rejections of this office action), necessitated by the applicant's 
amendment. Therefore, the rejection is maintained. 

Applicant states, (3) "The Office Action rejected Claims 3, 4, 13, 18, 19, 28, under 35 
U.S.C. 103(a). Applicant respectfully requests that the Examiner provide evidence of the 
Official Notice claimed limitations in the Office Action". In response to this applicant's request, 
for example, Coile et al., 6,108,300 (Hereinafter Coile) teaches limitations, "detecting the failure 
of the server and electing one of said load balancing servers as the new server (e.g., col., 5, lines 
3 - 24, e.g., col., 6, lines 40 - 62, col., 8, lines 2 - 28)", "server detecting the failure of other load 
balancing servers (e.g., col., 12, lines 35 - 54, col., 6, lines 40 - 62, col, 8, lines 2 - 28)" and 
"the server stops routing packets to any failed load balancing servers/back end Web servers (e.g., 
col, 12, Hnes 35 - 54, e.g., col, 6, lines 40 - 62, col, 8, lines 2 - 28)". The motivation would be 
obvious because with the Coile' s teachings, upon failure of the scheduler, another load balancing 
server can take over scheduling task to assign servers for the client requests. The other load 
balancing server will then receive the client requests for processing, i.e., schedule them 
according the scheduling algorithm. By discontinuing to route packets to any failed server 
would help prevent packets loss. Therefore, the rejection is maintained. 
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Applicant states, (4) "The Office Action rejected Claims 5, 6, 14, 15, 20, 21, 29 and 30 
under 35 U.S.C. 103(a). Applicant respectfully requests that the Examiner provide evidence of 
the Official Notice claimed limitations in the Office Action". In response to this applicant's 
request, for example. Masters 6,374,300 (Hereinafter Masters) clearly teaches limitations, 
"ser\'er scheduling sessions to servers based on a cookie or session ID (e.g., abstract, col., 10, 
lines 8 - 61), use of cookie injection to map a client to a specific server (e.g., abstract, col., 10, 
lines 8 - 61, col., 13, lines 1- 24), modify URLs in the HTML page in a packet to serve them 
from said content delivery network (e.g., col., 5, linesl4 - 61, col, 3, lines 21 - 50), HTML 
pages that have modified URLs are cached to improve performance (e.g., abstract, col., 10, lines 
8 - 61, col., 2, lines 24 - 64, col., 7, lines 1 - 16)". The motivation would be obvious because the 
Masters teachings would help use of the cookie for the client request so that the client request 
can be routed to a previously selected destination web server associated with the client. The 
client will be able to continue using the same web server support. As per Masters teachings, the 
cookie information can be manipulated as necessary. Hence, the client will be able to continue 
communicating with the server in a direct persistent manner. 

Applicant states, (5) "The Office Action rejected Claims 7, 8, 22 and 23 under 35 U.S.C. 
103(a). Applicant respectfully requests that the Examiner provide evidence of the Official 
Notice claimed limitations in the Office Action". In response to this applicant's request, for 
example, Hankinson et al., 6,799,202 (Hereinafter Hankinson) teaches limitations, "server 
decrypting and encrypting packet for SSL session (e.g., col, 3, lines 2 - 65)". The motivation 
would be obvious because with the Hankinson's teachings, the scheduler server can decrypt or 
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encrypt packets to support SSL session. Using SSL session client information would be handled 
in a secure manner. Therefore, the rejection is maintained. 

Applicant states, (6) "The Office Action rejected Claims 9-12, 24-27 under 35 U.S.C. 
103(a). Applicant respectfully requests that the Examiner provide evidence of the Official 
Notice claimed limitations in the Office Action". In response to this applicant's request, for 
example, Masters clearly teaches limitations, "URL based scheduling of packets (e.g., col., 5, 
lines 18 - 65), persistent connections in all its paths when required (e.g., col, 5, lines 22 - 59, 
col., 6, lines 8-31) and the load balancing server performing hash scheduling of packets (e.g., 
col., 15, Hnes 45 - col., 16, lines 21) and uses hash group based persistence to maintain its 
persistence tables (e.g., col., 5, Hnes 22 - 59, col., 15, Hne 57 - col, 16, line 24)". The 
motivation would be obvious because Masters teachings of cookie and persistence connections 
usage would help facilitate secure communication between the client and the Web server. The 
URL information in the https packet would provide information of the resource, which the client 
needs to access. The scheduling with hashing of packets will provide direct secure 
communication between the web server and the client. 

Claim Rejections - 35 USC § 112 
The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter, which the applicant regards as his invention. 

3. Amended claims 1, 7-9, 16, 22-24, are rejected under 35 U.S.C. 1 12, second paragraph, 
as being indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. 
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4. Amended claims 1 and 16, recite the limitations, "packet directly to said client", "the load 
balancing", "load balances said request packet", "response packet to said request packet". There 
is insufficient antecedent basis for this limitation in the claim. Due to amendment to the claims, 
multiple clients and muhiple request packets exist in the claims 1 and 16. It is not clear which 
client and request packet is referred by these limitations. 

5. Claims 7, 22, recite the limitations, "said request packet". There is insufficient 
antecedent basis for this limitation in the claim. Due to amendment to the claims, multiple 
request packets exist in the claims 1 and 16. It is not clear which request packet is referred by 
these limitations. 

6. Claims 8, 9, 23, 24, recite the limitations, "said client". There is insufficient antecedent 
basis for this limitation in the claim. Due to amendment to the claims, multiple clients exist in 
the claims 1 and 16. It is not clear which client is referred by these limitations. 

Claim Rejections - 35 USC §103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

8. Claims 1-4, 7, 8, 13, 16-19, 22, 23 and 28 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Zisapel et al, US Publication, 2002/0103846 Al, Aug. 1, 2002, "Load 
Balancing'*, Radware Limited (Hereinafter Zisapel-Radware) in view of Hassett et al., 6173,31 1, 
PointCast Inc (Hereinafter Hasett-PointCast). 
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9. As per claims 1 and 16, Zisapel-Radware clearly teaches a process and an apparatus (e.g., 
figure IC, abstract) to implement the following: 

routing packets through a load balancing array of servers across a network in a computer 
environment (e.g., router balancing load among cluster of servers over the network, figures 1 A - 
IC, paragraph 33, page 3), 

providing a plurality of load balancing servers (e.g., load balancing servers, figures 1 A - 
IC, paragraph 33, page 3); 

providing at least one back end Web server (e.g., content servers, SI, Sn, figures 1 A - 
IC, paragraph 33, page 3); 

wherein one of said load balancing servers is also a scheduler (e.g., LBl load balancing 
server also scheduling client requests, figures lA - IC, paragraph 33, page 3); 

wherein a request packet from a client is routed through said scheduler destined for the 
load balancing array (e.g., LBl load balancing server also scheduling client requests for LB2 
load balancing server, figures lA - IC, paragraphs 33 and 34, page 3); 

wherein said scheduler routes and load balances a request packet to a load balancing 
server (e.g., LBl load balancing server also scheduling client requests for LB2 load balancing 
server, figures 1 A - IC, paragraph 33, page 3); 

wherein said load balancing server routes and load balances said request packet to a back 
end Web server (e.g., LB2 load balancing server balancing load among content servers, SI, Sn, 
figures 1 A - IC, paragraph 33, page 3); 



Application/Control Number: 09/779,071 Page 8 

Art Unit: 2154 

wherein said back end Web server's response packet to said request packet is sent to said 
load balancing server (e.g., SI, Sn, content servers supporting client requests through LB2 load 
balancing server, paragraphs 8-10, pagel); and 

wherein said load balancing server sends said response packet directly to said client (e.g., 
LB2 load balancing server forwarding response from content servers, SI, Sn, to the clients, 
paragraphs 8-10, pagel). 

Zisapel-Radware also teaches handling of multiple requests for a client (e.g., paragraph 
36, page 3). 

However, Zisapel-Radware does not specifically mention about a request containing 
multiple packets and a scheduler supporting multiple clients . 

Hasett-PointCast clearly teaches a request containing multiple packets (e.g., abstract, col., 
7, lines 5 - 40, col., 3, lines 34 - 65) and a scheduler supporting multiple clients (e.g., abstract, 
col., 7, lines 5 - 40, col, 3, lines 34 - 65). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Zisapel-Radware with Hasett-PointCast in order to 
facilitate the scheduler to support multiple clients because the requests from the multiple clients 
would be processed by the scheduler. A request having multiple packets would help the request 
communicated from a client to the scheduler. The scheduler would receive requests from the 
clients and would forward the requests so that the requests from the clients are properly handled. 



10. 



As per claims 2 and 17, Zisapel-Radware et al. teaches the following: 
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scheduler routes and load balances client requests to itself (e.g., LBl load balancing 
server scheduling client requests for itself, figures lA - IC, paragraph 33, page 3). 

11. As per claims 3 and 18, Zisapel-Radware does not specifically mention about the use of 
detecting the failure of the server and electing one of said load balancing servers as the new 
server. "Official Notice" is taken that both the concept and advantages of providing to detect the 
failure of the server and electing one of said load balancing servers as the new server is well 
known and expected in the art. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include detecting the failure of the server and electing one of said load balancing 
servers as the new server with the teachings of Zisapel-Radware in order to facilitate replacing of 
scheduler in an event of the scheduler failure because upon failure of the scheduler, another load 
balancing server can take over scheduling task to assign servers for the client requests. The 
another load balancing server will then receive the client requests and will process them, i.e., 
schedule them according to the scheduling algorithm. 

12. As per claims 4 and 19, Zisapel-Radware does not specifically mention about the use of 
server detecting the failure of other load balancing servers and the server stops routing packets to 
any failed load balancing servers. "Official Notice" is taken that both the concept and 
advantages of providing server detecting the failure of other load balancing servers and the 
server stops routing packets to any failed load balancing servers, is well known and expected in 
the art. 
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It would have'been obvious to one of ordinary skill in the art at the time the invention 
was made to include server detecting the failure of other load balancing servers and the server 
stops routing packets to any failed load balancing servers, with the teachings of Zisapel-Radware 
in order to facilitate assigning client requests to another load balancing server instead of the 
failed load balancing server because stopping to route packets to the failed load balancing server 
would prevent dropping packets. Rerouting to the packets to the other load balancing server will 
help process the client requests. 

13. As per claims 7, 8, 22 and 23, Zisapel-Radware does not specifically mention about the 
use of server decrypting and encrypting packet for an SSL session. "Official Notice" is taken 
that both the concept and advantages of providing server decrypting and encrypting packet for an 
SSL session, is well known and expected in the art. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include server decrypting and encrypting packet for an SSL session, with the 
teachings of Zisapel-Radware in order to facilitate secure communicating between the client and 
the Web server because for processing and forwarding the packet to the Web server, the load 
balancing server will decrypt the packet when it receives from the client. The load balancing 
server will receive the response packet from the Web server, and it will encrypt the response 
packet before sending to the client. Using well-known SSL session implementation, the web 
server and the client will have direct secure communication. 
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14. As per claims 13 and 28, Zisapel-Radware does not specifically mention about the use of 
detecting and stop routing request packets to failed back end Web servers. "Official Notice" is 
taken that both the concept and advantages of providing detecting and stop routing request 
packets to failed back end Web servers is well known and expected in the art. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include detecting and stop routing request packets to failed back end Web servers 
with the teachings of Zisapel-Radware in order to facilitate accessing the other web server in an 
event of the web server failure because upon failure of the web server, other web server would 
help support the client requests. By stopping to route the packets to the failed web server would 
help prevent packets from dropping and the other web server would then handle the client 
requests. 

.15. Claims 5, 6, 9-12, 14, 15, 20, 21, 24-27, 29, 30, are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Zisapel-Radware and Hasett-PointCast in view of Masters 6,374,300 
(Hereinafter Masters). 

16. As per claims 5, 6, 14, 15, 20, 21, 29, 30, Zisapel-Radware and Hasett-PointCast do not 
specifically mention about the server scheduling sessions to servers based on a cookie or session 
ID and use of cookie injection to map a client to a specific server. 

Masters clearly teaches about the concept of server scheduling sessions to servers based 
on a cookie or session ED (e.g., abstract, col., 10, lines 8-61), and use of cookie injection to map 
a client to a specific server (e.g., abstract, col., 10, lines 8 - 61, col., 13, lines 1- 24), modify 
URLs in the HTML page in a packet to serve them from said content delivery network (e.g., col., 
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5, linesH - 61, col, 3, lines 21 - 50), HTML pages that have modified URLs are cached to 
improve performance (e.g., abstract, col., 10, lines 8 - 61, col., 2, lines 24 - page 4, line 34, col., 
7, lines 1-16). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Zisapel-Radware and Hasett-PointCast with Masters in 
order to facilitate scheduling based on cookie for persistent connection with the web server 
because using the cookie the client request can be routed to a previously selected destination web 
server associated with the client. The client will be able to continue using the same web server 
support. As per Masters teachings, the cookie information can be manipulated as necessary. 
Hence, the client will be able to continue communicating with the server in a direct persistent 
manner. 

17. As per claims 9-12, 24-27, Zisapel-Radware and Hasett-PointCast teach limitations 
rejected under claims 1 and 16. Zisapel-Radware also mentions about load balancing server 
establishes a connection with said client. However, Zisapel-Radware and Hasett-PointCast do 
not specifically mention about the client keeping connection alive with the server. "Official 
Notice" is taken that both the concept and advantages of the client keeping connection alive with 
server, is well known and expected in the art. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include the client keeping connection alive with the server, with the teachings of 
Zisapel-Radware and Hasett-PointCast in order to facilitate secure communicating between the 
client and the Web server because using well-known SSL session implementation, the web 



Application/Control Number: 09/779,071 Page 13 

Art Unit: 2154 

server and the client will have direct secure communication as long as the connection between 
the web server and the client is alive. ' 

Zisapel-Radware and Hasett-PointCast do not specifically mention about URL based 
scheduling of packets and the load balancing server performing hash scheduling of packets. 
Masters teaches about URL based scheduling of packets (e.g., col., 5, lines 18 - 65), persistent 
connections in all its paths when required (e.g., col., 5, lines 22 - 59, col, 6, lines 8-31) and the 
load balancing server performing hash scheduling of packets (e.g., col, 15, lines 45 - col, 16, 
lines 21) and uses hash group based persistence to maintain its persistence tables (e.g., col, 5, 
lines 22 - 59, col, 15, line 57 - col, 16, line 24). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Zisapel-Radware and Hasett-PointCast with Masters in 
order to facilitate secure communicating between the client and the Web server because the URL 
information in the https packet would provide information of the resource, which the client needs 
to access. The scheduling with hashing of packets will provide direct secure communication 
between the web server and the client. 

Conclusion 

THIS ACTION IS MADE FINAL, Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
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the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 



however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Haresh Patel whose telephone number is (571) 272-3973, The 
examiner can normally be reached on Monday, Tuesday, Thursday and Friday from 10:00 am to 
8:00 pm. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, John Follansbee can be reached on (571) 272-3964. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct,uspto.gov. Should you have questions on access to the Private PAIR 
systeni, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



Haresh Patel 



February 7, 2005 




